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AMENDMENTS TO THE CLAIMS 

(currently amended) A method of restarting resource reservation protocol (RSVP) 
processes in multiple network devices, the method comprising the computer- 
implemented steps of: 
entering a recovery mode; 

sending a Hello message to a first neighbor RSVP node , after entering the recovery 

mode , wherein the Hello message comprises a non-zero Recovery Time value; 
completing the recovery mode; 

sending a Hello message to the first neighbor RSVP node, after completing the 

recovery mode, wherein the Hello message comprises a Recovery Time value 
of zero. 

(original) A method as recited in Claim 1, further comprising the steps of: 
receiving, from a second neighbor RSVP node, a Hello message having a non-zero 

Recovery Time value; 
storing information specifying that the second neighbor RSVP node is in a recovery 

mode. 

(original) A method as recited in Claim 2, further comprising the steps of: 
receiving, from the second neighbor RSVP node, a Hello message having a zero 

Recovery Time value; 
storing information specifying that the second neighbor RSVP node is in a normal 

mode. 

(currently amended) A method as recited in Claim 2, wherein the step of creating and 

storing second information further comprises the steps of: 

receiving an RSVP PATH message that contains a Recovery Label; 

forwarding the PATH message to a downstream node with the Recovery Label only 

in response to determining that the PATH message is being sent to a node that 

is in recovery mode. 

(original) A method as recited in Claim 4, further comprising forwarding the PATH 
message to a downstream node with a Suggested Label in response to determining 
that the PATH message is being sent to a node that is not in recovery mode. 
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6. (original) A method as recited in any of Claims 4 or 5, wherein the determining step 
is performed based on whether a Recovery Time value in a previously received Hello 
message is non-zero. 

7. (original) A method of restarting RSVP processes in multiple network devices, the 
method comprising the computer-implemented steps of: 

entering a recovery mode; 

sending a Hello message to a first neighbor RSVP node, wherein the Hello message 

comprises a non-zero Recovery Time value; 
completing the recovery mode; 

sending a Hello message to the first neighbor RSVP node, wherein the Hello message 

comprises a Recovery Time value of zero; 
receiving, from a second neighbor RSVP node, a Hello message having a non-zero 

Recovery Time value; 
storing information specifying that the second neighbor RSVP node is in a recovery 

mode; 

receiving, from the second neighbor RSVP node, a Hello message having a zero 

Recovery Time value; 
storing information specifying that the second neighbor RSVP node is in a normal 

mode; 

receiving an RSVP PATH message that contains a Recovery Label; 

forwarding the PATH message to a downstream node with the Recovery Label only 

in response to determining that the PATH message is being sent to a node that 

is in recovery mode; 
forwarding the PATH message to a downstream node with a Suggested Label in 

response to determining that the PATH message is being sent to a node that is 

not in recovery mode. 

8. (currently amended) A computer-readable volatile or non- volatile medium carrying 
one or more sequences of instructions for restarting resource reservation protocol 
(RSVP) processes in multiple network devices, which instructions, when executed by 
one or more processors, cause the one or more processors to carry out the steps of: 
entering a recovery mode; 
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sending a Hello message to a first neighbor RSVP node , after entering the recovery 

mode, wherein the Hello message comprises a non-zero Recovery Time value; 
completing the recovery mode; 

sending a Hello message to the first neighbor RSVP node, after completing the 

recovery mode, wherein the Hello message comprises a Recovery Time value 
of zero. 

9. (currently amended) A computer-readable volatile or non- volatile medium as recited 
in Claim 8, further comprising instructions for performing the steps of: 
receiving, from a second neighbor RSVP node, a Hello message having a non-zero 

Recovery Time value; 
storing information specifying that the second neighbor RSVP node is in a recovery 
mode. 

10. (currently amended) A computer-readable volatile or non-volatile medium as recited 
in Claim 9, further comprising instructions for performing the steps of: 
receiving, from the second neighbor RSVP node, a Hello message having a zero 

Recovery Time value; 
storing information specifying that the second neighbor RSVP node is in a normal 
mode. 

1 1 . (currently amended) A computer-readable volatile or non- volatile medium as recited 
in Claim 9, wherein the step of creating and storing second information further 
comprises instructions for performing the steps of: 

receiving an RSVP PATH message that contains a Recovery Label; 

forwarding the PATH message to a downstream node with the Recovery Label only 

in response to determining that the PATH message is being sent to a node that 

is in recovery mode. 

12. (currently amended) A computer-readable volatile or non- volatile medium as recited 
in Claim 11, further comprising instructions for forwarding the PATH message to a 
downstream node with a Suggested Label in response to determining that the PATH 
message is being sent to a node that is not in recovery mode. 
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13. (currently amended) A computer-readable volatile or non- volatile medium as recited 
in any of Claims 1 1 or 12, wherein the determining step is performed based on 
whether a Recovery Time value in a previously received Hello message is non-zero. 

14. (currently amended) An apparatus for restarting resource reservation protocol (RSVP) 

processes in multiple network devices, comprising: 
means for entering a recovery mode; 

means for sending a Hello message to a first neighbor RSVP node , after entering the 
recovery mode , wherein the Hello message comprises a non-zero Recovery 
Time value; 

means for completing the recovery mode; 

means for sending a Hello message to the first neighbor RSVP node, after completing 
the recovery mode, wherein the Hello message comprises a Recovery Time 
value of zero. 

15. (original) An apparatus as recited in Claim 14, further comprising: 

means for receiving, from a second neighbor RSVP node, a Hello message having a 

non-zero Recovery Time value; 
means for storing information specifying that the second neighbor RSVP node is in a 

recovery mode. 

16. (original) An apparatus as recited in Claim 15, further comprising: 

means for receiving, from the second neighbor RSVP node, a Hello message having a 

zero Recovery Time value; 
means for storing information specifying that the second neighbor RSVP node is in a 

normal mode. 

17. (currently amended) An apparatus as recited in Claim 15, wherein the means for 
creating and storing second information further comprises: 

means for receiving an RSVP PATH message that contains a Recovery Label; 
means for forwarding the PATH message to a downstream node with the Recovery 

Label only in response to determining that the PATH message is being sent to 

a node that is in recovery mode. 

18. (original) An apparatus as recited in Claim 17, further comprising means for 
forwarding the PATH message to a downstream node with a Suggested Label in 
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response to determining that the PATH message is being sent to a node that is not in 
recovery mode. 

19. (original) An apparatus as recited in any of Claims 17 or 18, wherein the means for 
determining is based on whether a Recovery Time value in a previously received 
Hello message is non-zero. 

20. (currently amended) An apparatus for restarting resource reservation protocol (RSVP) 
processes in multiple network devices, comprising: 

a network interface that is coupled to the data network for receiving one or more 

packet flows therefrom; 
a processor; 

one or more stored sequences of instructions which, when executed by the processor, 

cause the processor to carry out the steps of: 
entering a recovery mode; 

sending a Hello message to a first neighbor RSVP node , after entering the recovery 

mode , wherein the Hello message comprises a non-zero Recovery Time value; 
completing the recovery mode; 

sending a Hello message to the first neighbor RSVP node, after completing the 

recovery mode, wherein the Hello message comprises a Recovery Time value 
of zero. 

21. (original) An apparatus as recited in Claim 20, further comprising sequences of 
instructions for performing the steps of: 

receiving, from a second neighbor RSVP node, a Hello message having a non-zero 

Recovery Time value; 
storing information specifying that the second neighbor RSVP node is in a recovery 

mode. 
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22. (original) An apparatus as recited in Claim 21, further comprising the steps of: 
receiving, from the second neighbor RSVP node, a Hello message having a zero 

Recovery Time value; 
storing information specifying that the second neighbor RSVP node is in a normal 
mode. 

23. (currently amended) An apparatus as recited in Claim 21, wherein the step of 
creating and storing second information further comprises the steps of: 
receiving an RSVP PATH message that contains a Recovery Label; 
forwarding the PATH message to a downstream node with the Recovery Label 

only in response to determining that the PATH message is being sent to a 
node that is in recovery mode. 

24. (original) An apparatus as recited in Claim 23, further comprising forwarding the 
PATH message to a downstream node with a Suggested Label in response to 
determining that the PATH message is being sent to a node that is not in recovery 
mode. 

25. (original) An apparatus as recited in any of Claims 23 or 24, wherein the 
determining step is performed based on whether a Recovery Time value in a 
previously received Hello message is non-zero 

26. (currently amended) A method of restarting resource reservation protocol (RSVP) 
processes in multiple network devices, the method comprising the computer-implemented 
steps of: 

receiving a first downstream message containing first path data; 

based on said first path data, generating first recovery data, wherein the first 

recovery data includes data identifying a neighbor RSVP node and a target 

RSVP node ; 

sending a second downstream message containing the first recovery data to the 
neighbor RSVP node; 

receiving a first upstream message from the neighbor RSVP node containing 
second recovery data, wherein the second recovery data identifies an 
original RSVP route includes a second path data : and 
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based on the second recovery data, updating the first path data to correspond to 
the original RSVP route second path data . 

27. (currently amended) A method as recited in Claim 26, further comprising: 
causing the neighbor RSVP node to receive the second downstream message 

containing the first recovery data; 
based on the second downstream message, causing the neighbor RSVP node to 

retrieve original the second path dat a, wherein the original path data 

indicates the original RSVP route ; 
based on the original second p ath data, causing the neighbor RSVP node to 

generate second recovery data; and 
causing the neighbor RSVP node to send the first upstream message containing 

the second recovery data; 
wherein the second path data comprises an RSVP route . 

28. (currently amended) A method as recited in Claim 27, wherein causing the 
neighbor RSVP node to retrieve original the second path data includes: 

causing the neighbor RSVP node to determine if the second downstream message 

is associated with incoming RSVP PATH data; 
causing the neighbor RSVP node to determine if the second downstream message 

is associated with forwarding data; and 
based on determining that the second downstream message is associated with both 

incoming RSVP PATH data and forwarding data, causing the neighbor 

RSVP node to retrieve original the second p ath data. 

29. (previously presented) A method as recited in Claim 26, wherein the first and 
second downstream messages are RSVP PATH messages and the first upstream message 
is an RSVP RESV message. 

30. (previously presented) A method as recited in Claim 26, wherein the first 
downstream message is an RSVP PATH message containing a Recovery Label. 
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3 1 . (previously presented) A method as recited in Claim 26, wherein the first path 
data indicates an RSVP route. 

32. (previously presented) A method as recited in Claim 26, wherein the first path 
data is an Explicit Route Object. 

33. (previously presented) A method as recited in Claim 26, further comprising: 
based on the first downstream message, generating outgoing path data, wherein 

the outgoing path data includes an Explicit Route Object corresponding to 
the first path data received in the first downstream message. 

34. (previously presented) A method as recited in Claim 26, wherein generating first 
recovery data includes performing a partial expansion of an Explicit Route Object 
contained in a received RSVP PATH message and storing the results of the partial 
expansion in a Recovery Explicit Route Object. 

35. (currently amended) A method as recited in Claim 34, wherein perfoiTning a 
partial expansion of the Explicit Route Object contained in the received RSVP PATH 
message includes: 

based on forwarding data, identifying a strict next hop in an RSVP path, wherein 

the strict next hop is a neighbor RSVP node; and 
based on the first path data, identifying a loose hop in an RSVP path , wherein the 

loose hop identifies a target RSVP node . 

36. (previously presented) A method as recited in Claim 26, further comprising: 
identifying a Recovery Explicit Route Object in the first upstream message 

received from the neighbor RSVP node, wherein the first upstream 

message also includes reservation data; 
before processing the reservation data, extracting the Recovery Explicit Route 

Object from the first upstream message; and 
based on the Recovery Explicit Route Object, updating a Explicit Route Object in 

the first path data. 
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37. (currently amended) A method of restarting resource reservation protocol (RSVP) 
processes in multiple network devices, the method comprising the computer-implemented 
steps of: 

receiving a first RSVP PATH message with a Recovery Label from an upstream node, 

wherein the first RSVP PATH message includes an Explicit Route Object 

containing data identifying a target RSVP node ; 
identifying forwarding data associated with the first RSVP PATH message; 
based on the forwarding data, identifying a neighbor RSVP node; 
performing a partial expansion of the Explicit Route Object of the first RSVP PATH 

message to include the identified neighbor RSVP node and the identified target 

RSVP node ; 

storing the results of the partial expansion in a Recovery Explicit Route Object; 
sending a second RSVP PATH message to the neighbor RSVP node, wherein the second 

RSVP PATH message includes the generated Recovery Explicit Route Object; 
causing the neighbor RSVP node to receive the second RSVP PATH message containing 

the Recovery Explicit Route Object; 
based on the Recovery Explicit Route Object, causing the neighbor RSVP node to 

retrieve original path data, wherein the original path data indicates the original 

RSVP route; 

based on the original path data, causing the neighbor RSVP node to generate a second 

Recovery Explicit Route Object; 
causing the neighbor RSVP node to send an RSVP RESV message containing the second 

Recovery ERO; 

receiving the RSVP RESV message from the neighbor RSVP node; and 

based on the second Recovery Explicit Route Object contained in the received RSVP 

RESV message, updating the Explicit Route Object to correspond to the original 

RSVP route. 

38. (currently amended) A computer-readable volatile or non- volatile medium 
carrying one or more sequences of instructions for restarting resource reservation 
protocol (RSVP) processes in multiple network devices, which instructions, when 
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executed by one or more processors, cause the one or more processors to carry out the 
steps of: 

receiving a first downstream message containing first path data; 

based on said first path data, generating first recovery data, wherein the first 

recovery data includes data identifying a neighbor RSVP node and a target 

RSVP node ; 

sending a second downstream message containing the first recovery data to the 

neighbor RSVP node; 
receiving a first upstream message from the neighbor RSVP node containing 

second recovery data, wherein the second recovery data identifies an 

original RSVP route includes a second path data ; and 
based on the second recovery data, updating the first path data to correspond to 

the original RSVP route second path data . 

39. (currently amended) A computer-readable volatile or non-volatile medium as 
recited in Claim 38, further comprising instructions for performing the steps of: 

causing the neighbor RSVP node to receive the second downstream message 

containing the first recovery data; 
based on the second downstream message, causing the neighbor RSVP node to 

retrieve original the second p ath dat a, wherein the original path data 

indicates the original RSVP route ; 
based on the original second p ath data, causing the neighbor RSVP node to 

generate second recovery data; and 
causing the neighbor RSVP node to send the first upstream message containing 

the second recovery data; 
wherein the second path data comprises an RSVP route . 

40. (currently amended) A computer-readable volatile or non- volatile medium as 
recited in Claim 39, wherein causing the neighbor RSVP node to retrieve original the 
second p ath data includes: 

causing the neighbor RSVP node to determine if the second downstream message 
is associated with incoming RSVP PATH data; 
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causing the neighbor RSVP node to determine if the second downstream message 

is associated with forwarding data; and 
based on determining that the second downstream message is associated with both 

incoming RSVP PATH data and forwarding data, causing the neighbor 

RSVP node to retrieve original the second path data. 

41 . (currently amended) A computer-readable volatile or non-volatile medium as 
recited in Claim 38, wherein generating first recovery data includes performing a partial 
expansion of the Explicit Route Object contained in a received RSVP PATH message 
and storing the results of the partial expansion in a Recovery Explicit Route Object. 

42. (currently amended) A computer-readable volatile or non- volatile medium as 
recited in Claim 38, further comprising instructions for performing the steps of: 

identifying a Recovery Explicit Route Object in the first upstream message 

received from the neighbor RSVP node, wherein the first upstream 

message also includes reservation data; 
before processing the reservation data, extracting the Recovery Explicit Route 

Object from the first upstream message; and 
based on the Recovery Explicit Route Object, updating the Explicit Route Object 

in the first path data. 

43. (currently amended) An apparatus for restarting resource reservation protocol 
(RSVP) processes in multiple network devices, comprising: 

means for receiving a first downstream message containing first path data; 
based on said first path data, means for generating first recovery data, wherein the 

first recovery data includes data identifying a neighbor RSVP node and a 

target RSVP node ; 

means for sending a second downstream message containing the first recovery 
data to the neighbor RSVP node; 

means for receiving a first upstream message from the neighbor RSVP node 
containing second recovery data, wherein the second recovery data 
identifies an original RSVP route includes a second path data ; and 
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based on the second recovery data, means for updating the first path data to 
correspond to the original RSVP route second path data . 

44. (currently amended) An apparatus as recited in Claim 43, further comprising: 
means for causing the neighbor RSVP node to receive the second downstream 

message containing the first recovery data; 
based on the second downstream message, means for causing the neighbor RSVP 

node to retrieve original the second path dat a, wherein the original path 

data indicates the original RSVP route ; 
based on the original second p ath data, means for causing the neighbor RSVP 

node to generate second recovery data; and 
means for causing the neighbor RSVP node to send the first upstream message 

containing the second recovery data; 
wherein the second path data comprises an RSVP route . 

45. (currently amended) An apparatus as recited in Claim 44, wherein causing the 
neighbor RSVP node to retrieve original the second path data includes: 

causing the neighbor RSVP node to determine if the second downstream message is 

associated with incoming RSVP PATH data; 
causing the neighbor RSVP node to determine if the second downstream message is 

associated with forwarding data; and 
based on determining that the second downstream message is associated with both 

incoming RSVP PATH data and forwarding data, causing the neighbor RSVP 

node to retrieve original the second p ath data. 

46. (previously presented) An apparatus as recited in Claim 43, wherein generating 
first recovery data includes performing a partial expansion of the Explicit Route Object 
contained in a received RSVP PATH message and storing the results of the partial 
expansion in a Recovery Explicit Route Object. 

47. (previously presented) An apparatus as recited in Claim 43, further comprising: 
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means for identifying a Recovery Explicit Route Object in the first upstream 

message received from the neighbor RSVP node, wherein the first 

upstream message also includes reservation data; 
before processing the reservation data, means for extracting the Recovery Explicit 

Route Object from the first upstream message; and 
based on the Recovery Explicit Route Object, means for updating the Explicit 

Route Object in the first path data. 

48. (currently amended) An apparatus for restarting resource reservation protocol 
(RSVP) processes in multiple network devices, comprising: 

a network interface that is coupled to the data network for receiving one or more packet 

flows therefrom; 
a processor; 

one or more stored sequences of instmctions which, when executed by the processor, 
cause the processor to carry out the steps of: 
receiving a first downstream message containing first path data; 
based on said first path data, generating first recovery data, wherein the first 

recovery data includes data identifying a neighbor RSVP node and a target 

RSVP node ; 

sending a second downstream message containing the first recovery data to the 

neighbor RSVP node; 
receiving a first upstream message from the neighbor RSVP node containing 

second recovery data, wherein the second recovery data identifies an 

original RSVP route includes a second path data : and 
based on the second recovery data, updating the first path data to correspond to 

the original RSVP route second path data . 
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49. (currently amended) An apparatus as recited in Claim 48, further comprising 
sequences of instructions for performing the steps of: 

causing the neighbor RSVP node to receive the second downstream message 

containing the first recovery data; 
based on the second downstream message, causing the neighbor RSVP node to 

retrieve original the second path dat a, wherein the original path data 

indicates the original RSVP route ; 
based on the original second p ath data, causing the neighbor RSVP node to 

generate second recovery data; and 
causing the neighbor RSVP node to send the first upstream message containing 

the second recovery data; 
wherein the second path data comprises an RSVP route . 

50. (currently amended) An apparatus as recited in Claim 49, wherein causing the 
neighbor RSVP node to retrieve original the second path data includes: 

causing the neighbor RSVP node to determine if the second downstream message is 

associated with incoming RSVP PATH data; 
causing the neighbor RSVP node to determine if the second downstream message is 

associated with forwarding data; 
based on determining that the second downstream message is associated with both 

incoming RSVP PATH data and forwarding data, causing the neighbor RSVP 

node to retrieve original the second p ath data. 

51. (previously presented) An apparatus as recited in Claim 49, wherein generating 
first recovery data includes performing a partial expansion of the Explicit Route Object 
contained in a received RSVP PATH message and storing the results of the partial 
expansion in a Recovery Explicit Route Object. 

52. (previously presented) An apparatus as recited in Claim 49, further comprising sequences 
of instructions for performing the steps of: 
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identifying a Recovery Explicit Route Object in the first upstream message received from 
the neighbor RSVP node, wherein the first upstream message also includes 
reservation data; 

before processing the reservation data, extracting the Recovery Explicit Route Object 

from the first upstream message; and 
based on the Recovery Explicit Route Object, updating the Explicit Route Object in the 

first path data. 
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